Pages: 1 2 3 [4] 5 6 7 8 9 10 11 .. 11 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 27 post(s) |
Tamer
|
Posted - 2009.09.20 18:05:00 -
[91]
Edited by: Tamer on 20/09/2009 18:07:24
what about showinfo: links ? It was important feature to make guides, marketlists, fittinglists etc. --------------------- English language (100) ETA: 17d 13h 54m 13s |
Wollari
Phoenix Industries Wicked Nation
|
Posted - 2009.09.20 23:40:00 -
[92]
Is the minimum size of the browser window (content) now limited to 590x210 pixel? Or are you smaller pages still possible? I mean 590 is fine for me, everything smaller quite hard to display if you've a page full with informations.
btw. what happend that the browser is currently disabled on SiSi and only available for CCP controlled pages?
|
Sky Grunthor
Minmatar Conflagration. Wildly Inappropriate.
|
Posted - 2009.09.20 23:57:00 -
[93]
Edited by: Sky Grunthor on 21/09/2009 00:01:52 Have started a wiki page to track desired javascript functions.
http://wiki.eveonline.com/wiki/IGB_Javascript_Wish_List
* javascript is stripped out of links.
Also, what right click functionality will be available?
the current link formats to show a character image or item image or have a right clickable link is a very nice feature that should probably be maintained. ------------------------------------------------- Search: Sky Grunthor |
Sasha J
Caldari Kumovi Sons of Tangra
|
Posted - 2009.09.21 10:37:00 -
[94]
One of the features I'll like to see: Mapping game-events with javascript events.
For example:
Client.onjump = function() { // refresh page document.href = document.href; }
That is something that can be used by makers of eve-minimap at http://www.eve-maps.com/ or jump planners (Dotlan,...).
Possibilities are really endless.
|
Serge Bastana
Gallente GWA Corp
|
Posted - 2009.09.21 11:36:00 -
[95]
I tried selecting the url currently shown in the address bar to paste another over it but the selection is lost when I right click to use the paste fuction. I had to totally clear the address bar to be able to paste a new address into it.
Looking far far better than the old IGB though, vast improvement already even with a few bugs. Keep chiselling away, ppl will be so happy to see this when Dominion is released.
|
Sleepkevert
Amarr Rionnag Alba Against ALL Authorities
|
Posted - 2009.09.21 12:21:00 -
[96]
Edited by: Sleepkevert on 21/09/2009 12:24:01
Originally by: Sasha J One of the features I'll like to see: Mapping game-events with javascript events.
this would actually be awesome!
And how about a way to get some colors from the color scheme the user is using. That way we can at least try to make our webpages blend in with the EVE color scheme. Which is always a good thing imho.
Originally by: Tamer what about showinfo: links ? It was important feature to make guides, marketlists, fittinglists etc.
read back, this is going to be a javascript function as mentioned by the devs. _
Add your own line! |
Heroldyn
|
Posted - 2009.09.21 12:34:00 -
[97]
i would like a function to disable javascript
|
Wollari
Phoenix Industries Wicked Nation
|
Posted - 2009.09.21 19:32:00 -
[98]
Originally by: Sasha J One of the features I'll like to see: Mapping game-events with javascript events.
For example:
Client.onjump = function() { // refresh page document.href = document.href; }
That is something that can be used by makers of eve-minimap at http://www.eve-maps.com/ or jump planners (Dotlan,...).
Possibilities are really endless.
I know that the old browser has the "sessionchange" header which I can send via php.header() functions, but it seems that the current implementation won't react on it. The Client.onjump function which gets called is a nice idea. But in most cases, you you might want to reload the complete page anyway.
Atm I don't see any possibilities for minimaps as the browser window is limited to 590x210 pixels. You can't make the browser window smaller. I don't know if CCP will keep this or if they'll allow to make the window smaller.
Atm I can't check anything with the current IGB functions because it's limited to CCP Sites only.
Quote: [ 2009.09.20 23:59:05 ] (notify) Browser lockdown has been enabled due to security concerns. The in-game browser will be restricted to access CCP-controlled web sites only until further notice.
|
Wollari
Phoenix Industries Wicked Nation
|
Posted - 2009.09.21 20:00:00 -
[99]
btw. @CCP
-------
It would be nice if you could allow 127.0.0.1 localhost and *.localhost to be accessed in the IGB to allow Developers to test things against their own webserver (if not already done).
That would be nice and noone would be at risk because noone else expect the developer himself.
btw. will CCP check every URL which gets passed to the client (send via network packets to CCP) or is the privacy of the browser, the user and the called urls given? I'm not speaking about hacking sites that try to overtake your browser, but I'm thinking about the paranoia of alliances and users.
-----
I've an additional thought how to secure the HTTP Headers or Client (Javascript stuff, if you provide it). Many users don't trust the HTTP Headers because every good browser with some header modifications an fake them. There's no official way how to check the identity of those IGB users.
My Idea is: Add an additional header: something like HTTP_EVE_HASH and HTTP_EVE_HASHUNTIL. This security hash is valid for HTTP_EVE_CHARID until the Cache Timer is over. Via API Call and the given Hash and CharID, a webdeveloper is able to verify the correct identity of the user.
The hash could be something like md5(charID + corpID + allianceID + clientIP + ticketid(valid until)) on the serverside.
Let me do a little flowchart
Client Server CCP/API -------------------------------------------------------------------------- Open Webpage ---> Shows Page <--- Ask for Trust Accept Trust Reload Page ---> Extract CharID/HASH Send CharID+Hash ---> Validate Hash Process API Result <--- Send Result yes/no Save CharID + Hash + IP + Until in Session Show Webpage <--- Send Webpage else (result=no) Show Webpage <--- Send Error Page
(Next Client on Webpage)
Open Webpage ---> Check Session If Hash = BrowserHash and HashUntil > now() and CharValid == true and IP=SessIP, etc Show Webpage <--- Send Webpage else destroy session request reload page Reload Page <--- Send http header reload
|
Rn Bonnet
Black Omega Security Pandemic Legion
|
Posted - 2009.09.21 21:21:00 -
[100]
The above suggestion would be very nice. Some way to verify in game identity beyond "x in alliance chat" would be appreciated. Stuff like auto-registration for team speak services, forums, etc. could be based off of this without requiring some kind of api key.
Quote: There will be others coming up in the next iteration, we're looking at "Show Info", "Show Route", "Show Map" and "View Fitting", along with maybe a couple others depending on timing. We are also very open to suggestions for methods IGB-site authors would like to have access to, so if you're dying to interact with the game in a certain manner, please let us know!
"Show Market Details" and "Show Contract ID" would be very useful in general.
|
|
Johnathan Roark
Caldari Quantum Industries RAZOR Alliance
|
Posted - 2009.09.22 06:51:00 -
[101]
Originally by: Wollari btw. @CCP
-------
It would be nice if you could allow 127.0.0.1 localhost and *.localhost to be accessed in the IGB to allow Developers to test things against their own webserver (if not already done).
That would be nice and noone would be at risk because noone else expect the developer himself.
btw. will CCP check every URL which gets passed to the client (send via network packets to CCP) or is the privacy of the browser, the user and the called urls given? I'm not speaking about hacking sites that try to overtake your browser, but I'm thinking about the paranoia of alliances and users.
I haven't checked the new browser, but my understanding was that the old browser has never gone through ccp. localhost should work.
Originally by: Wollari
I've an additional thought how to secure the HTTP Headers or Client (Javascript stuff, if you provide it). Many users don't trust the HTTP Headers because every good browser with some header modifications an fake them. There's no official way how to check the identity of those IGB users.
My Idea is: Add an additional header: something like HTTP_EVE_HASH and HTTP_EVE_HASHUNTIL. This security hash is valid for HTTP_EVE_CHARID until the Cache Timer is over. Via API Call and the given Hash and CharID, a webdeveloper is able to verify the correct identity of the user.
The hash could be something like md5(charID + corpID + allianceID + clientIP + ticketid(valid until)) on the serverside.
Let me do a little flowchart
Client Server CCP/API -------------------------------------------------------------------------- Open Webpage ---> Shows Page <--- Ask for Trust Accept Trust Reload Page ---> Extract CharID/HASH Send CharID+Hash ---> Validate Hash Process API Result <--- Send Result yes/no Save CharID + Hash + IP + Until in Session Show Webpage <--- Send Webpage else (result=no) Show Webpage <--- Send Error Page
(Next Client on Webpage)
Open Webpage ---> Check Session If Hash = BrowserHash and HashUntil > now() and CharValid == true and IP=SessIP, etc Show Webpage <--- Send Webpage else destroy session request reload page Reload Page <--- Send http header reload
I'd love something like that
Quantum Industries is recruiting! |
schurem
Silver Snake Enterprise Systematic-Chaos
|
Posted - 2009.09.22 11:30:00 -
[102]
i bug reported an issue with certain sites where the browser seems to be unsure about the proper length of the page. it jitters up and down, making reading or clicking links impossible.
|
Leebe
|
Posted - 2009.09.22 13:24:00 -
[103]
Edited by: Leebe on 22/09/2009 13:25:21
Originally by: Wollari
It would be nice if you could allow 127.0.0.1 localhost and *.localhost to be accessed in the IGB to allow Developers to test things against their own webserver (if not already done).
this already works. at least http://localhost:8080 worked ;)
the hash thing sounds a bit complicated .. it would be sufficient to have something like
hash(secretsalt+charid+ domainname_of_called_website )
e.g. your site is www.secreteve.com/test.php the hash would be md5( secret-salt + charid + "secreteve.com" )
and to check if that is really the char you could call the eve api with
validate.aspx?charid=<charid>&url=secreteve.com&hash=<hashfromheader>
that way the hash would be unique for every character and only for your domain...
- you would only need to check it once against the api and you can store it for later checking - you can't use it on different sites because it is bound to your domainname - no timing or expire of the hashes is necessary
|
|
CCP Ronin
C C P
|
Posted - 2009.09.22 13:34:00 -
[104]
Originally by: Wollari
@CCP
-------
It would be nice if you could allow 127.0.0.1 localhost and *.localhost to be accessed in the IGB to allow Developers to test things against their own webserver (if not already done).
That would be nice and noone would be at risk because noone else expect the developer himself.
btw. will CCP check every URL which gets passed to the client (send via network packets to CCP) or is the privacy of the browser, the user and the called urls given? I'm not speaking about hacking sites that try to overtake your browser, but I'm thinking about the paranoia of alliances and users.
Your browsing goes through your local internet connection, it does not get passed up to CCP servers.
I assume you're asking to allow access to localhost while the browser is in lockdown mode.. that's not a bad idea, I'll look into that for a future release.
Originally by: Wollari
I've an additional thought how to secure the HTTP Headers or Client (Javascript stuff, if you provide it). Many users don't trust the HTTP Headers because every good browser with some header modifications an fake them. There's no official way how to check the identity of those IGB users.
My Idea is: Add an additional header: something like HTTP_EVE_HASH and HTTP_EVE_HASHUNTIL. This security hash is valid for HTTP_EVE_CHARID until the Cache Timer is over. Via API Call and the given Hash and CharID, a webdeveloper is able to verify the correct identity of the user.
The hash could be something like md5(charID + corpID + allianceID + clientIP + ticketid(valid until)) on the serverside.
Let me do a little flowchart
I understand the need for this very well, and we would like to enable some sort of secure authentication. I'm not sure yet if we will go through the EVE API, or end up using a third-party authentication tool, but we are in the process of researching this.
|
|
Shibz 7175
|
Posted - 2009.09.22 22:30:00 -
[105]
Sorry for the long post. It is hard for me to contain my excitement. There are three points to this post...
Firstly, can we maybe get some more information in the HTTP headers such as: - Is the player docked? - Ship type - Fleet/Wing/Squad ID, and maybe fleet role (boss, booster, fleet commander, ...) - Destination (and maybe autopilot settings so that we can calculate the route that autopilot will choose)
Also, it would be really really nice if users could somehow drag/drop items or ship fittings into a text box in the browser to post a link to that item. Or even if they had to link the items the same way that they link them in chat, it would still open many possibilities for development.
Example: 1. While making a forum post, you drag an item into the text box, and it inserts a link. 2. When users click on the link, IGB users will have the standard eve item info window for that item pop up. When firefox/ie users click on it, the website author would be able to open a popup to the item's page in the item database website of their choice (http://wiki.eveonline.com/wiki/Item_Database)
And if you could do this with ship fittings too... *drool*
Lastly, In response to the posts about a way to prevent HTTP header spoofing, I think that we need a private key signature (RSA maybe?) of ALL of the eve http header data. This signature needs to be generated on the Eve game server using a super secret CCP private key, and sent to the eve client on every session change. The public key would then need to be released to the public so that we can validate the signature. Both PHP and ASP .net have classes available for RSA, so once some example code is published, it should be trivial for developers to implement this.
Thanks for reading!
|
Amoranis
Gallente
|
Posted - 2009.09.22 22:46:00 -
[106]
omg i love u ccp ty... :D!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -AMO- |
Arimathea Anthalas
Game-Over
|
Posted - 2009.09.22 23:54:00 -
[107]
Edited by: Arimathea Anthalas on 22/09/2009 23:54:19
Originally by: CCP Ronin
So in regards to the flickering thing, my only experience with seeing the previous texture in place of what I'm trying to view is when I load a website, close the browser, and then reopen the browser. I briefly see the last website I was viewing before the texture is replaced by the new website. I would love to hear more info about the problem as many of you are experiencing it though, especially if it seems to be 64-bit related. Keep those bug reports coming!
Vista 64 ATI card Recently built system
The problem is apparent for me on any visited website (CNN is a good example). Eventually the problem causes actual "corruption" on the page, where text is misaligned depending on where it is on the page and what the CSS and layout for the page looks like. I think it does have something to do with the previous webpage visited, but it seems to occur no matter what. I am on a 64-bit (i7) machine, with 64-bit Vista.
For instance, if CNN is set as the homepage, any mouseover event in the 'latest news' section causes significant redrawing of the page which leads to jitter and flicker.
Thanks, AA
|
Sky Grunthor
Minmatar Conflagration. Wildly Inappropriate.
|
Posted - 2009.09.23 04:33:00 -
[108]
The javascript method list in the wiki has been updated it looks like.
http://wiki.eveonline.com/w/index.php?title=IGB_Javascript_Methods&stable=0 ------------------------------------------------- Search: Sky Grunthor |
Latheth
Gallente Veyr
|
Posted - 2009.09.23 10:22:00 -
[109]
Originally by: Shibz 7175
- Is the player docked?
HTTP_EVE_STATIONNAME should work already ?
Originally by: Shibz 7175
- Ship type
This one please? pretty with sugar?
|
Chi Quan
Bibkor Enterprises
|
Posted - 2009.09.23 17:27:00 -
[110]
hate to bring this up, now we have the new shiny, but what about malicious drive-by-downloads? ---- Ceterum censeo blasters need some tracking love |
|
Sinaroma
|
Posted - 2009.09.23 21:17:00 -
[111]
when does dominion officialy come out? :o
|
Catari Taga
Centre Of Attention Rough Necks
|
Posted - 2009.09.24 08:53:00 -
[112]
Adding my voice to the requests for adding shiptype to the trusted headers!
|
Serge Bastana
Gallente GWA Corp
|
Posted - 2009.09.24 17:47:00 -
[113]
Edited by: Serge Bastana on 24/09/2009 17:53:40 It could use a zoom function, not all of us can read the really small text on some sites, for instance I just opened the forums using the IGB and I find the text too small too read on my higher res screen so often have to zoom in, when using Chrome.
A similar feature would be of great benefit to us oldies
Edit: And the damn things prevented me from maximizing my eve window again dammit ------------------------------------------------ You either need a punch up the throat or a good shag.
Nobody round here is offering the second one therefore your choices are limited! |
Wollari
Phoenix Industries Wicked Nation
|
Posted - 2009.09.24 21:58:00 -
[114]
Originally by: CCP Ronin I assume you're asking to allow access to localhost while the browser is in lockdown mode.. that's not a bad idea, I'll look into that for a future release.
Exactly :-)
Originally by: Leebe validate_hash.aspx?charid=<charid>&url=secreteve.com&hash=<hashfromheader>
that way the hash would be unique for every character and unique for every domain...
- you would only need to check it once against the api and you can store it for later checking - the website owner can't use it on different sites because it is bound to his domainname - no timing or expire of the hashes is necessary
I'm not worried about the website owner ... I'm worried about people who're trying to retrieve other peoples API keys, with varios methods to finally get access to a hostile alliance board and/or teamspeak, etc.
Self registration serivces are always nice. But people can get API keys from various sources ... former alliance board, killboards, other alliance service pages, etc. Especially if people tend to be lazy and not reset their keys.
If you wanna provide a secure way how to verify the true identity of an Eve Online Ingame pilot you have to use some kind of ticket based keys .. not just a shared secret like domain names. Cookies and HTTP Headers can easyly be faked just to bypass the alliance registration system and afterwards you'll just switch back, etc.
|
Arkady Sadik
Minmatar Gradient Electus Matari
|
Posted - 2009.09.25 21:58:00 -
[115]
Originally by: Wollari My Idea is: Add an additional header: something like HTTP_EVE_HASH and HTTP_EVE_HASHUNTIL. This security hash is valid for HTTP_EVE_CHARID until the Cache Timer is over. Via API Call and the given Hash and CharID, a webdeveloper is able to verify the correct identity of the user.
This has the problem that anyone you authenticate yourself to can authenticate himself as you to anyone else. E.g. if you buy some items at some EVE web store, the web store could mirror your alliance's forum (if both use this authentication mechanism). Not good.
To do this "right", you need a challenge from the web server.
1) Client requests page 2) Server sends EVE-Need-Auth: <challenge> 3) Client replies EVE-Auth: <charid> <token> 4) Server verifies (<charid>, <challenge>, <token>) via API (API returns True only if all three match)
Server uses normal sessions in cookies.
This avoids the abuse scenario I point out above with the forums. The forum server will send a different challenge, and only that challenge will work together with the token received.
|
Leebe
|
Posted - 2009.09.25 22:13:00 -
[116]
Edited by: Leebe on 25/09/2009 22:17:56 Edited by: Leebe on 25/09/2009 22:13:17
Originally by: Wollari
If you wanna provide a secure way how to verify the true identity of an Eve Online Ingame pilot you have to use some kind of ticket based keys .. not just a shared secret like domain names. Cookies and HTTP Headers can easyly be faked just to bypass the alliance registration system and afterwards you'll just switch back, etc.
No you don't need tickets ... I don't think you understood my suggestion. By the way it's based on an authentication system that is used by payment providers like paypal to make sure calls to their system are orginated from their merchants server.
Take as an example the character "Leebe" with the Character ID 12345. This character has also a secret id 23456 which is only known by ccp (and the users client)
This character requests a page from his trusted server mycorp.com. Moondoggy will then create a hash for this page based on the secret id and the domain name: hash( 23456 + "mycorp.com") = AFAFHASH.
So the mycorp.com server will get the request information: HTTP_EVE_CHARID: 12345 HTTP_EVE_HASH: AFAFHASH
Now, to verify that the user is really the character the mycorp.com server can send following request to the server:
validate_hash.aspx?charid=12345&url=mycorp.com&hash=AFAFHASH
the api server that knows the secret id 23456 can then create the hash itself and compare it to value from the request and can confirm then that it's really the user.
Since nobody except ccp knows the secret id of a character nobody can forge the hash for a character on a given domain.
For additional security they might change the secret key once a week or once a month.. but one advantage is as long as the secret id is the same the hashes for the domains won't change and so you don't need to check the api on every login.
|
Haskell
Gallente
|
Posted - 2009.09.25 22:46:00 -
[117]
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. |
Leebe
|
Posted - 2009.09.26 00:18:00 -
[118]
Edited by: Leebe on 26/09/2009 00:24:18 Edited by: Leebe on 26/09/2009 00:20:31 Edited by: Leebe on 26/09/2009 00:18:48
Originally by: Haskell
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.
Not really... oauth is a bit more then that ;) My suggestion is a simple signature added to the request that can't be forged, is different for every domain, but can be checked by the website by just doing one api call.
It would allow authentication to the website without revealing even the basic api key, not even the userid of the account. :9
It has nothing to do with granting/revoking rights which is a lot more complicated in the end. Remember that requests from the ingame browser are only on a character level and don't contain even the user(account)id .. and I hope it stays that way :9
IMHO stuff like that would better fit into the account management and not into the game client.
|
Jondar Valador
Intergalactic Crossing Core Factor
|
Posted - 2009.09.26 04:04:00 -
[119]
Quote: The procedure entry point TTGetNewFontName could not be located in the dynamic link library t2embed.dll
However, MSDN says it should be there. It's not. No TTGetNewFontName in t2embed.dll, I grepped. W2K+SP4+rollup+latest updates.
I hope you didnt take a huge dump allover my playing experience just to graft the abomination that chrome**** is into the client.
I want to play internet spaceships NOT USE A ****ING ****TY BROWSER INGAME.
|
Leebe
|
Posted - 2009.09.26 11:20:00 -
[120]
Edited by: Leebe on 26/09/2009 11:22:02 Edited by: Leebe on 26/09/2009 11:21:01
Originally by: Jondar Valador
Quote: The procedure entry point TTGetNewFontName could not be located in the dynamic link library t2embed.dll
However, MSDN says it should be there. It's not. No TTGetNewFontName in t2embed.dll, I grepped. W2K+SP4+rollup+latest updates.
I hope you didnt take a huge dump allover my playing experience just to graft the abomination that chrome**** is into the client.
I want to play internet spaceships NOT USE A ****ING ****TY BROWSER INGAME.
I don't think swearing gets you any further. Chromium don't support win2k and from what I've read in the chrome dev groups it's not likely that it will ever run on that outdated os.
btw... if you check the minimum system specs for eve you will notice that w2k is not an official supported os for eve: eve minimal requirements
Quote: Please note that Windows 95, 98, ME, NT and 2000 are not supported.
|
|
|
|
|
Pages: 1 2 3 [4] 5 6 7 8 9 10 11 .. 11 :: one page |
First page | Previous page | Next page | Last page |