EVE Search - Moondongie

Check My IP Information

All Channels

Test Server Feedback

Moondongie

» Click here to find additional results for this topic using Google

Monitor this thread via RSS [?]


Author	Thread Statistics \| Show CCP posts - 27 post(s)
Haskell Gallente	Posted - 2009.09.25 22:46:00 - [1] Originally by: Leebe For additional security they might change the secret key once a week or once a month.. Add a nounce and a timestamp and you've almost re-invented OAuth. OAuth is a simple and secure mechanism to give a website access to an API without giving the website your user name and password. I'd love if users could give websites limited or full API access without the hassle of having to lookup and enter an API key.
Haskell Gallente	Posted - 2009.10.05 23:14:00 - [2] Originally by: Zendoren If you could allow us to link directly to contracts and/or pull information from specific contracts so that one could build a fully functional web-store-front via the contract system. This would be great! Linking to a contract (you need to specify the contract ID) has been added to the list of supported IGB methods by CCP Nimbus today.
Haskell Gallente	Posted - 2009.10.05 23:45:00 - [3] This is how the right-click menu of a showinfo: link with a character ID currently looks like (Apocrypha IGB): Link Does this still work with Moondoggie? If not, will there be JavaScript methods that replace the menu items? I think this is quite useful to have in web applications, especially "Send Message", "Give Money" and "Set Standings".
Haskell Gallente	Posted - 2009.10.09 18:01:00 - [4] Originally by: Haskell This is how the right-click menu of a showinfo: link with a character ID currently looks like (Apocrypha IGB): Link Does this still work with Moondoggie? If not, will there be JavaScript methods that replace the menu items? I think this is quite useful to have in web applications, especially "Send Message", "Give Money" and "Set Standings". To answer my own question: CCP Pleognost has stated in the Fanfest vid that all right-click menus are gone and won't return. Originally by: Sky Grunthor I would think we could suggest a "Client.ShowContextMenu(anyID, x, y)" that would pop up the context menu associated with the given anyID at the x and y position within the area of the IGB window. This kind of thing would be inline with their approach to the new igb. I'd prefer if all menu items could be invoked directly. With respect to griefing potential I think, for example, a pre-populated "Give Money" window that shows the exact (3000000 ISK) and approximate (3.0 M ISK) amount and counts down 5 seconds before the "Confirm" button is enabled (as seen in Firefox) is less error-prone than requiring users to enter the exact digits themselves as with the current right-click menu. Originally by: CCP Nimbus (Evelopedia) ~~Client~~ CCPEVE Originally by: CCP Pleognost (Evelopedia) In the original IGB, and in earlier builds on SiSi, the JavaScript methods used a single-argument calling convention, where multiple arguments were concatenated into a single string, delimited by some sort of substring - in many cases, this was a double-slash (//). As we now have the capability to process multiple arguments, we are shifting Moondoggie to behave like a proper software package. As such, we are deprecating support for old-style arguments Two great changes that I like Originally by: CCP Pleognost (Evelopedia) RequestTrust * This method will pop-up a trust prompt in the client, allowing the user to either grant the trust request, ignore it, or always ignore trust requests from your site. * The page will not be automatically refreshed if the user grants the trust request. Trust will take effect the next time the user refreshes the page, or navigates within the site. IMO this ~~suc...~~ has bad usability. When a user confirms the trust pop-up, no immediate effect will be visible. So website developers will have to give instructions what to do after confirming the prompt ("Restart the computer to make the changes take effect... yadda"). It'd be really great if RequestTrust would return a boolean value if trust was granted, so the website can refresh itself or do fancy AJAX stuff without refreshing the page to take advantage of the now available information.
Haskell Gallente	Posted - 2009.10.10 16:20:00 - [5] Originally by: CCP Nimbus Originally by: Haskell IMO this has bad usability. When a user confirms the trust pop-up, no immediate effect will be visible. So website developers will have to give instructions what to do after confirming the prompt ("Restart the computer to make the changes take effect... yadda"). It'd be really great if RequestTrust would return a boolean value if trust was granted, so the website can refresh itself or do fancy AJAX stuff without refreshing the page to take advantage of the now available information. It should not be necessary to refresh the page for trust to take effect - although to recieve the headers obviously will require a refresh. As for the request trust call returning confirmation, as far as I know it is currently not possible to have the Javascript functions return values for technical reasons. However, I believe this is something which we might be looking to change. No promises, though. So the JavaScript methods will be enabled immediately. That's great. But consider a web-page with some button that is supposed to invoke a CCPEVE JavaScript method. Currently, there are three situations in which pressing the button doesn't do anything: * there's an error in the page's JavaScript code, * the CCPEVE JavaScript method is not implemented yet, or * the website isn't trusted. For a user, it's impossible to find out the reason why the button has no effect. (And, as can be seen in this thread, most developers assume it's reason #1 when it's reason #2.) The only way for a web-page to find out if it's trusted is by looking at the HTTP headers. To avoid the problem, a web-page could disable the button if the header isn't set to "Yes". But it cannot simply enable the button after invoking RequestTrust because the user could deny the request and would then be left with an enabled button without effect again. BTW what happens when an already trusted page invokes RequestTrust? Will the function call be silently ignored as well (adding a fourth reason to the list above)?
Haskell Gallente	Posted - 2009.10.15 17:35:00 - [6] The IGB Known Issues page doesn't list any crashes anymore. Is this already on SiSi? I've tested today, and resizing the browser window very fast crashes the whole process structure.
Haskell Gallente	Posted - 2009.10.22 16:06:00 - [7] I've played a bit with the RequestTrust method in the current build (109210) and stumbled upon some issues: * It's possible to request trust for a different site (e.g., http://example.com/path/to/file.html requesting trust for "http://www.google.com") * Denying trust in this case ("Ignore Always") correctly adds "http://www.google.com/" to the list of Trusted Sites as "Not Trusted". But all subsequent calls of RequestTrust from http://example.com/path/to/file.html are ignored. * ShowInfo works when a site is not on the list of Trusted Sites, and also even when the site has been added to the list of Trusted Sites as "Not Trusted". * Upon opening the window, for a few milliseconds the text "A page is requesting..." doesn't take the full available width and requires a scrollbar. Some ideas: * What if RequestTrust wasn't a separate method but integrated into each of the other JavaScript methods? For example, invoking ShowInfo would first ask the user if he really wants to perform this action, and if confirmed then show the Info window. The confirmation window would have four buttons: "Continue" (Allow once), "Abort" (Ignore once), "Trust website" (Allow always), "Block website" (Ignore always). This allows the user to have fine grained control over which methods the website may call, and also solves the problem of the website needing to detect if it's trusted or not. * It would be really really nice if method calls weren't silently ignored. If the method calls are blocked in the browser process, is it maybe possible to throw something like an AccessDeniedException or return an old-fashioned error code to the caller?
Haskell Gallente	Posted - 2009.10.26 23:19:00 - [8] Originally by: Tonto Auri Post a screenshot of this page rendering from inside an EVE. The new IGB browser uses the same engine as Chrome 1.5 and renders the page like this (100/100 but linktest failed): Linkage
Haskell Gallente	Posted - 2009.10.28 17:15:00 - [9] Edited by: Haskell on 28/10/2009 17:20:10 Confirming the resize crashes don't occur any longer after today's patch (build 110372). Instead resizing the window is horribly slow now and seems to squeeze the window contents until the mouse is released. JavaScript methods have been changed to start with a lower case letter: CCPEVE.showInfo works now. CCPEVE.requestTrust/RequestTrust has apparently been disabled. Any other changes?
Haskell Gallente	Posted - 2009.10.29 22:46:00 - [10] Originally by: Synex Any news on possibly getting EVECCP.transferISK(charID, amount, reason); which would pop up the 'transfer ISK' dialog filled in. Like this? Linkage

Haskell Gallente	Posted - 2009.10.30 15:08:00 - [11] Edited by: Haskell on 30/10/2009 15:12:57 Originally by: CCP Nimbus Originally by: Haskell resizing the window is horribly slow now and seems to squeeze the window contents until the mouse is released. Could you bug report your resizing issues and include your system specs? Done. Bug ID: 86098. Includes frapsed video
Haskell Gallente	Posted - 2009.11.05 13:35:00 - [12] Originally by: CCP Nimbus Not going to happen for Dominion release, but we might take a look at it after that. Does that mean IGB development will continue after the release of Dominion, or will you guys be moved to new projects? I enjoyed the open communication in this thread and would be really sad to see this end after the release. Any update on the possibility of not silently ignoring invalid method calls?

COPYRIGHT NOTICE
EVE Online, the EVE logo, EVE and all associated logos and designs are the intellectual property of CCP hf. All artwork, screenshots, characters, vehicles, storylines, world facts or other recognizable features of the intellectual property relating to these trademarks are likewise the intellectual property of CCP hf. EVE Online and the EVE logo are the registered trademarks of CCP hf. All rights are reserved worldwide. All other trademarks are the property of their respective owners. CCP hf. has granted permission to EVE-Search.com to use EVE Online and all associated logos and designs for promotional and information purposes on its website but does not endorse, and is not in any way affiliated with, EVE-Search.com. CCP is in no way responsible for the content on or functioning of this website, nor can it be liable for any damage arising from the use of this website.